Windows vs. NetWare Troubleshooting Tips Compiled by Brett Warthen (Infinite Technologies) December 7, 1992 (2nd Edition) The most important troubleshooting tip for solving conflicts between Windows and NetWare is to remember to use logical deduction and the process of elimination to isolate conflicts. For example, if you are using a 3rd party memory manager like QEMM or 386-to-the-MAX, de-install it and try your configuration running Microsoft's HIMEM.SYS that ships with Windows 3.1 instead (try without EMM386). Then, if the problem is related to your memory manager, you should contact that vendor for technical support suggestions. If you are loading any additional TSRs or device drivers, try your configuration without them loaded, and add them back into your system one by one to determine which is causing the conflict. If you are using EMSNETX or XMSNETX, try using regular old NETX instead. While far from being a comprehensive guide to all possible Windows and NetWare conflicts, this document contains some troubleshooting tips for common problems running Windows in the NetWare environment. (Thanks to everyone in NOVB Section 15, the Windows section of the Novell NetWire forums on CompuServe for helping to compile this list. Acknowledgements are presented at the end of this document.) Recommendations for ALL Systems: 1.) In the Windows SYSTEM.INI file, verify the following settings: Under the [boot] section header: network.drv=netware.drv Under the [386Enh] section header: network=*vnetbios,vnetware.386,vipx.386 (NOTE: *vnetbios can cause some problems with the current IBM LAN Support drivers.) 2.) Update to the latest NetWare drivers, a minimum level of IPX v3.10 (or IPXODI v1.20) and NETX v3.26 for proper support of the Windows 3.1 environment. 3.) Check for duplicate copies of the NWPOPUP.EXE, VNETWARE.386, VIPX.386 and NETWARE.DRV files. (You may find one version in the Windows directory and another in Windows\SYSTEM.) Make sure that the only versions that remain on your system are 1992 dated versions. (The latest versions are on the Windows 3.1 diskettes, but you many have to manually expand them. Or you can download WINUP*.ZIP from NOVLIB Library 5 on | CompuServe/NetWire. Additionally, the "security | enhancement" updates include new versions of LSL, | IPXODI, NETX, VNETWARE.386, VIPX.386, NETWARE.DRV, and | can be found in the NOVFILES area on CompuServe, or | requested from Novell at 1-800-NETWARE.) 4.) Verify that the NETWARE.DRV file is approximately 125,000 bytes in size. We've seen plenty of problems where installation routines did not properly expand this file. The NetWare DOS/Windows Workstation Kit NWSETUP installation procedure is particularly notorious for this type of problem. 5.) Use WINSTART.BAT with care. There is a bug with WINSTART.BAT processing under Windows 3.1 on some PCs, which can cause Windows to hang-up when exiting. The NetWare DOS/Windows Workstation Kit NWSETUP installation procedure creates a dummy WINSTART.BAT which can trigger this problem. 6.) If you want to receive broadcast messages while in Windows, then make sure that NWPOPUP.EXE is included in the "load=" statement in your WIN.INI file. 7.) In your NET.CFG (or SHELL.CFG) file, be sure to allocate plenty of file handles. FILE HANDLES=80 is a recommended minimum. 8.) In your NET.CFG (or SHELL.CFG) file, allocate additional stacks for IPX/SPX usage by specifying GET LOCAL TARGET STACKS = 5. The default setting is 1 stack, which can lead to system lockup problems when receiving NetWare broadcast messages. If you plan on making use of IPX/SPX applications on a regular basis, then you should increase this value to GET LOCAL TARGET STACKS = 10. | (The GET LOCAL TARGET STACKS setting works around a bug | in NETX v3.26, and is not necessary if you are running | NETX v3.31 or later, which fixes this bug.) 9.) If you are running DR-DOS 6, make sure that you have the April Business update installed for Windows 3.1 compatibility. | This file can be downloaded from the Novell Library | forum (NOVLIB) on CompuServe, DR6UP2.EXE in Library 12. | 9.) If you are attempting to use the Burst Mode shell | (BNETX) with Windows 3.1, BNETX v3.31 or later is | required for Windows compatibility. Windows hangs while loading: 1.) For Windows 3.0, is your network card set to IRQ 2 or 9, 10 or higher? If it is, then you will need to install the VPICDA.386 patch (included in WINUP*.ZIP in NOVLIB on CompuServe). Copy VPICDA.386 into your Windows\SYSTEM directory, and edit your SYSTEM.INI, replacing the line "device=*vpicd" with "device=vpicda.386". NOTE: VPICDA.386 is not required for Windows 3.1, you should specify "device=*vpicd" instead. 2.) Try loading Windows with a command-line parameter of /D:XSV (e.g., WIN /D:XSV). Each of the letters following the /D: are equivalent to placing the following statements under the [386Enh] section header in SYSTEM.INI, one time only: X -> EMMExclude=A000-EFFF S -> SystemRomBreakpoint=OFF V -> VirtualHDIrq=OFF If Windows now works, use a process of elimination to determine which of the parameters was the key to your success. WIN /D:X is most often the solution to these types of problems, which indicates that the shared RAM area used by your network adapter is not properly excluded from your memory manager, or the Windows internal memory manager. For Windows internal memory manager, you exclude this memory range with an EMMExclude=xxxx-xxxx statement under the [386Enh] section header of your SYSTEM.INI. If you are unsure of this range, use EMMExclude=A000- FFFF while troubleshooting. As an example, to exclude a 16KB range of memory at segment D000h, you would specify EMMExclude=D000-D3FF. For the Microsoft EMM386.EXE memory manager, use a /X=xxxx-xxxx parameter to tell it what range of memory to exclude for your network card. | For the DR-DOS EMM386.SYS memory manager, use a | /E=xxxx-xxxx parameter to tell it what range of memory | to exclude for your network card. 3.) Are you loading MS-DOS 5 SHARE or running MS-DOS 4 (DOS 4 automatically loads SHARE if you have a hard disk larger than 32MB)? If you can avoid loading SHARE, do so. If you cannot, load SHARE before IPX and NETX. Place the statement "FILES=XXX" in your CONFIG.SYS file. XXX is 255 minus 2 (reserved handles) minus the number of files handles defined in your NET.CFG (or SHELL.CFG) file. The default is 40. Therefore, if you are using the default, you would set FILES=213 in your CONFIG.SYS. | Windows for Workgroups includes a version of SHARE that | runs as a Windows enhanced mode virtual device driver, | VSHARE.386. This version reportedly addresses the | conflicts between the NetWare shells, SHARE and | Windows, however at the time of this writing, this | driver is not available on CompuServe. To install | VSHARE.386, specify "device=VSHARE.386" in the [386Enh] | section of SYSTEM.INI instead of loading the DOS | SHARE.EXE program. 4.) There are known conflicts between the IBM LAN Support drivers for Token Ring and the "*vnetbios" driver supplied with Windows. If you can use the NetWare drivers that talk directly to the Token Ring adapter, this should work. Otherwise, do not include "*vnetbios" on the "network=" line under the [386Enh] section header of your SYSTEM.INI file, and avoid running any applications that use NETBIOS under Windows. 5.) Are you loading SuperStor 2.0, a disk compression device driver? There is a deadlock problem between NETX v3.26 and SuperStor 2.0 under Windows. As a temporary work-around, use the NETX v3.22 shell and contact the software manufacturer for other possible work-arounds. 6.) There could be an interrupt or I/O conflict between your network card, and Windows searching your COM ports for a mouse. These are the default COM port interrupt (IRQ) & I/O assignments: COM1 = IRQ 4, I/O 3F8h COM2 = IRQ 3, I/O 2F8h COM3 = IRQ 4, I/O 2E8h COM4 = IRQ 3, I/O 2E0h (NOTE: On IBM PS/2s, the settings for COM3 or COM4 are different.) | Windows looks for a serial mouse starting at the | highest numbered COM port in your system. So, if a | serial mouse is attached to COM1 (IRQ 4), and your | network adapter is configured for IRQ 3, when Windows | searches for a mouse on COM2, using IRQ 3, this may | disrupt the network connection. In the [386Enh] section header of SYSTEM.INI, you can specify COM#Irq=-1 to disable a particular port. For example, specify COM2Irq=-1 to disable COM2. You could also specify MaxCOMPort=2 under the [386Enh] section header to ensure that COM3 and COM4 are not | being used. COM4 may sometimes conflict with Arcnet | boards configured for I/O address 2E0h. System Hang-ups running RCONSOLE or other IPX/SPX applications under Windows: 1.) Verify that you have all of the latest drivers for running IPX/SPX under Windows. A minimum version level of IPX v3.10 or IPXODI v1.20 is required. For Windows in 386 Enhanced Mode, make sure that you have VIPX.386 v1.10 or v1.11. (Use the NetWare VERSION utility to run against VIPX.386 to determine the version.) Make sure that you do not have duplicate copies of VIPX.386 elsewhere in your path. In particular, check both the Windows and Windows\SYSTEM directories for duplicates. Furthermore, ensure that VIPX.386 is included in the "network=" statement under the [386Enh] section header of your SYSTEM.INI. For Windows in Standard Mode, make sure that TBMI2 is loaded before going into Windows, but this will not be sufficient for many IPX/SPX applications. | 2.) If you are running NETX v3.26 or lower, place the statement GET LOCAL TARGET STACKS = 10 in your NET.CFG (or SHELL.CFG) file to allocate additional stacks for IPX/SPX multi-tasking. 3.) For RCONSOLE, if all servers do not show up in the | display, you need RCONSOLE v2.9 or higher, which is currently available for download from CompuServe/NetWire as RCNSLE.ZIP in NOVLIB Library 4. System Hang-ups running NETBIOS applications under Windows: 1.) Follow the same guidelines as described for running IPX/SPX applications under Windows above. 2.) Include a statement "TimerCriticalSection=10000" under the [386Enh] section header of SYSTEM.INI. This statement will help prevent deadlocks and re-entrancy problems associated when network activity is generated from a timer interrupt. Cannot locate NETWARE.DLL error when loading NetWare Tools or another application: 1.) See the "Recommendations for ALL Systems" section. There is no NETWARE.DLL, it is actually NETWARE.DRV, which is either not specified as "network.drv=netware.drv" under the [boot] section of SYSTEM.INI, or the NETWARE.DRV file is corrupt. Remote Boot PCs cannot find WINA20.386: 1.) WINA20.386 is a DOS 5 file that is required for running Windows 3.0 in enhanced mode with DOS=HIGH in the CONFIG.SYS. (It is supposedly no longer used by Windows 3.1.) Windows looks for WINA20.386 when it is loading in the root of the boot drive *UNLESS* you include SWITCHES=/W in your CONFIG.SYS file, and specify "device=d:\path\WINA20.386" under the [386Enh] section header of SYSTEM.INI to tell Windows where to find this driver. Remote Boot PCs cannot find EMM386.EXE: 1.) If you are using the Microsoft EMM386.EXE device driver to provide expanded memory emulation, then be aware that Windows needs to reload EMM386.EXE when Windows is started to load a virtual device driver for upper memory management in 386 enhanced mode. Windows looks for EMM386.EXE in the drive/directory that it was loaded from in CONFIG.SYS. If you need to specify an alternate path, include a /y=d:\path\EMM386.EXE parameter when loading EMM386.EXE in CONFIG.SYS. This path should be a path that will be valid when Windows is later started. | Remote Boot PCs running QEMM v6.0x will not run Windows in | enhanced mode: | | 1.) Similar to the EMM386 issue above, if you are running | QEMM v6.0x, several files need to be reloaded when | Windows v3.x is being initialized. These files are | WINHIRAM.VXD and WINSTLTH.VXD. Windows looks for these | files in the drive/directory that QEMM was loaded from | in CONFIG.SYS. If you need to specify an alternate | path, include a VXDDIR=d:\path parameter when loading | QEMM in CONFIG.SYS. This path should be a path that | will be valid when Windows is later started. Broadcast Messages do not display when in Windows applications: 1.) Verify that NWPOPUP.EXE is included in the "load=" statement of your WIN.INI file. 2.) In the Windows Control Panel, Network Options, ensure that the "Messages Enabled" button is clicked. 3.) See the "Recommendations for ALL Systems" section. Broadcast Messages lock up Windows: 1.) See the "Recommendations for ALL Systems" section. In particular, focus on the GET LOCAL TARGET STACKS statement that should be placed in your NET.CFG (or | SHELL.CFG) file. It is recommended that you upgrade to | NETX v3.31 or higher to avoid this problem. Ensure that this statement is echoed to the screen when IPX or IPXODI is loaded. DOS DIR Command Shows No Files when used on Network Drives: 1.) See the "Recommendations for ALL Systems" section. In particular, focus on the GET LOCAL TARGET STACKS statement that should be placed in your NET.CFG (or | SHELL.CFG) file. It is recommended that you upgrade to | NETX v3.31 or higher to avoid this problem. Ensure that this statement is echoed to the screen when IPX or IPXODI is loaded. How do I update to IPX.COM v3.10?: 1.) If you installed Windows 3.1 for a Novell network, it should have copied an IPX.OBJ file to your Windows\SYSTEM directory. Copy this file to your WSGEN or SHGEN diskette, and re- run the WSGEN or SHGEN procedure to create an updated IPX. Now might be a good time to consider migrating to the IPX ODI drivers, which do not require this generating process, and are generally more up-to-date, as Novell is no longer certifying new drivers for the linkable IPX.COM. The IPX ODI drivers are included in the DOSUP*.ZIP file in NOVLIB Library 5 on CompuServe/NetWire, and documentation is included in ODIDOC.ZIP in this same library. Controlling Windows Swap Files: 1.) The following statements under the [386Enh] section header of SYSTEM.INI control the creation and placement of Windows temporary swap files in 386 enhanced mode: Paging=Off (disables paging) MaxPagingFileSize=xxxx (max size of temporary swap file in KB) PagingDrive=d (paging files will be placed in the root of this drive) PagingFile=d:\path\SWAPFILE (Windows 3.1 only: name to use for swap file, overrides PagingDrive entry) 2.) The following statement under the [NonWindowsApp] section of SYSTEM.INI controls the placement of swap files created when switching between DOS applications in Windows Standard mode: SwapDisk=c:\path If this path is not specified, then Windows will default to the directory pointed to by the TEMP DOS environmental variable (which many Windows applications also use for controlling where they create temporary files), or the root directory of your first hard disk if the TEMP variable is not defined. 3.) The following statements under the [386Enh] section header of SYSTEM.INI control the location of permanent swap files (Windows 3.1 Only): PermSwapDOSDrive=c (drive letter) PermSwapSizeK=xxxx (desired size of permanent swap file) Windows is very slow while loading: 1.) This is probably due to Windows creating a temporary swap file when loading, possibly to a network drive. Under NetWare 2.x, this process is much slower than with NetWare 3.x. See "Controlling Windows Swap Files" above for more information. Printing to a NetWare Print Queue results in 65,535 copies requested: | 1.) This is a problem with the NE3200 EISA network adapter | driver. In the NET.CFG file, under the "LINK DRIVER | NE3200" section, include a "Double Buffer" statement. | Note that there are a number of 32-bit EISA adapters | that are OEM versions of the NE3200, including the | Intel EtherExpress/32. Loading NetWare Windows Drivers when not attached to network displays a warning message that the network is not present: 1.) Specify "NetWarn=0" under the [windows] section of your WIN.INI file, which tells Windows not to warn you about loading network drivers when no network is present. Garbage when printing from Windows to a network printer: | 1.) Are you running PSERVER? If you are, then you need to | be running PSERVER v1.22 or later. PSERV1.ZIP can be | downloaded from NOVLIB Library 6 on CompuServe/NetWire. | (Browse on PSERV*.ZIP to find the latest version.) 2.) What is your CAPTURE statement that you execute before going into Windows? You need to specify the NT (no tab expansion) flag, and I recommend a timeout of at least 60 seconds (TI=60). For PostScript printers, NB (no banner) and NFF (no form feed) are also necessary. NA (no autoendcap) is also required in some Windows configurations. The NA flag will cause you some problems if you are printing to LPTx.OS2 (or LPTx.DOS in Windows 3.1) instead of LPTx. While previous recommendations were to print to LPTx.OS2, these recommendations have been superseded because of updated Novell drivers. If you are using all Windows applications, you should be able to set TI=0 to disable the timeout feature, as it is not necessary if applications print through the standard Windows APIs. | NETX v3.26 has a bug in handling CAPTURE timeout values | under some configurations when running with the IPX ODI | drivers. Instead of the timeout occurring after an xx | second pause in printing, the timeout occurs xx seconds | after printing begins, which can cause considerable | printing problems for large print jobs. NETX v3.31 | addresses this problem. 3.) In the Windows Control Panel/Printers/Configure menu, disable the print manager if it is not already disabled. (Since NetWare print jobs are spooled to disk anyway, using the print manager when spooling to a network printer is redundant and can slow things down.) 4.) Make sure that you have the latest NetWare drivers for Windows. For Windows 3.1, the drivers that ship with the product are satisfactory. For Windows 3.0, you need VNETWARE.386 v2.0, the version that is included in the WINUP*.ZIP file in NOVLIB Library 5 on CompuServe/NetWire. 5.) Type CAPTURE SHOW in a DOS Window after going into Windows, and make sure that these settings are the same as what were set before going into Windows. A Windows "permanent list" setting can override the CAPTURE that you set before going into Windows. Check the [network] section of your WIN.INI and delete any statements that reference print captures to avoid confusion. 6.) When all else fails, try connecting the printer to the workstation directly to verify that this is indeed a network problem. | 7.) Are you running RPRINTER on a workstation running | Windows in enhanced mode? If so, see the "RPRINTER and | Windows" section of this document. Windows hangs when opening a DOS Window or DOS application: 1.) Make sure that you have the NetWare drivers for Windows loaded: "network.drv=netware.drv" under the [boot] section of SYSTEM.INI, and for 386 enhanced mode, "network.drv=vnetware.386" (*vnetbios & vipx.386 may also be specified in this command) under the [386Enh] section of SYSTEM.INI. 2.) For Windows 3.0, is your network card set to IRQ 2 or 9, 10 or higher? If it is, then you will need to install the VPICDA.386 patch (included in WINUP*.ZIP in NOVLIB on CompuServe). Copy VPICDA.386 into your Windows\SYSTEM directory, and edit your SYSTEM.INI, replacing the line "device=*vpicd" with "device=vpicda.386". NOTE: VPICDA.386 is not required for Windows 3.1, you should specify "device=*vpicd" instead. 3.) You may be running out of file handles. Increase the value specified in the FILE HANDLES statement in your NET.CFG (or SHELL.CFG) file. 4.) You may be experiencing swap file corruption. Refer to the section entitled "Controlling Windows Swap Files" to ensure that swap files are being created in the correct locations. (If you are swapping to the network, swap files must be stored in unique directories.) 5.) A TSR that you are running may require that you specify "TimerCriticalSection=10000" under the [386Enh] section header of your SYSTEM.INI DOS Environment Missing or Corrupt in DOS windows: 1.) Make sure that you have the NetWare drivers for Windows loaded: "network.drv=netware.drv" under the [boot] section of SYSTEM.INI, and for 386 enhanced mode, "network.drv=vnetware.386" (*vnetbios & vipx.386 may also be specified in this command) under the [386Enh] section of SYSTEM.INI. 2.) Verify that your NetWare drivers are up to date. Review "Recommendations for ALL systems" in this document. Changing directories on a network drive in one window affects all windows: 1.) If you have NWShareHandles=TRUE in the [NetWare] section of your WIN.INI file, then this is what is causing the problem. 2.) If you have a TASK MODE = statement in your NET.CFG (or SHELL.CFG) file, then this is what is causing the problem. NetWare MENU program freezes or performs erratically (like you would notice ) after executing Windows from a menu option: 1.) This is a known incompatibility, and there is not a fix at this time. RPRINTER and Windows: 1.) These don't peacefully co-exist at this time, and the best solution is to purchase a 3rd party alternative. Alternatives include hardware based solutions like network cards installed in laser printers, as well as the Castelle LanPress and Intel NetPort. Software solutions like Fresh Technologies Printer Assist, | BrightWork's PS-Print and Intel's LanSpool are also reported to work. | I-Queue! Server (IQS) from Infinite Technologies is an | additional software based print server solution that is | compatible with Windows. In addition to providing | Windows compatibility, IQS has also been shown to | prevent hair loss, primarily the type that occurs when | you're pulling your hair out trying to make RPRINTER | work. A 30-day trial version of I-Queue! Server | can be downloaded under the filename IQS.ZIP in Library | 4 of the NOVVEN forum on CompuServe. Or call Infinite | Technologies at 410-363-1097 for additional | information. (A subtle plug for my own company. ) If you want to try RPRINTER, you can also experiment with the following suggestions. 2.) Run Windows in Standard Mode (WIN /S) on PCs that are running RPRINTER. 3.) Disable the Windows print manager. 4.) Try increasing the SPX timeout values specified in your NET.CFG (or SHELL.CFG). For example: SPX ABORT TIMEOUT = 4000 SPX LISTEN TIMEOUT = 2500 5.) Try installing Microsoft's VPD.386 driver as "device=vpd.386" under the [386Enh] section header of SYSTEM.INI. This driver can be downloaded from the Microsoft Software Library on CompuServe (GO MSL) under the filename VPD386.EXE. 6.) Review "Recommendations for ALL Systems" to ensure that you have the latest drivers and proper configuration support. | Running Windows 3.1 on a non-dedicated NetWare 2.x File Server | | 1.) This is NOT possible. The NetWare 2.x operating system | requires all available extended memory and exclusive | control of protected mode operations. | Problems Retrieving Files from Network Drives with Microsoft Word | for Windows | | 1.) Include the statement "NovellNet=Yes" in the [Microsoft | Word] section of your WIN.INI file. | Problems running Windows in Enhanced Mode with Thomas Conrad | Token Ring Cards | | 1.) When using the TCTOKSH ODI driver, in the NET.CFG file, | under the "LINK DRIVER TCTOKSH" section, include a | "NON_VDS" statement. | Windows Application no longer runs after flagging the executable | file Execute Only | | 1.) The execute-only attribute will not work with any | executable files that use internal overlays, which is | the inherent design of all Windows applications. You | CANNOT use the execute-only attribute with Windows | applications. Undocumented Option for Changing Drives and Printers Built into NetWare Drivers There is an undocumented option built into NETWARE.DRV that gives you hot-key access to a dialog that allows you to change drive mappings, print queue assignments, and attach/detach to other servers in your network. Under the [options] section of your NETWARE.INI file, include a statement "NetWareHotKey=123". Restart Windows and press F12. Any time you press F12, it will pop-up a selection menu that gives you access to a menu of NetWare functions. Do not minimize this window or switch away from it while active, or the application that you popped this window up over will no longer be able to receive keystrokes. Where to Go For More Information "Running Windows on NetWare" by Stephen Saxon from M&T Books "Networking Windows: NetWare Edition" by Howard Marks, Kristin Marks and Rick Segal from Sams Books "Microsoft Windows Resource Kit" from Microsoft "Windows 3.1 Secrets" by Brian Livingston | "NetWare Power Tools for Windows" by Charles Rose from | Bantam Books (coming soon) NOVB Section 15 in the NetWire Family of Forums on CompuServe RoseNet OnLine BBS - 703-799-2536 +------------------------------------------------------------------+ | Compiled by Brett Warthen (Infinite Technologies). | | | | Address comments via e-mail... | | | | MHS: Brett @ Infinite (via CSERVE or NHUB) | | CompuServe: >MHS:Brett@Infinite | | (or 76704,63 in NOVVEN Sec 4 or NOVB Sec 15) | | Internet: Brett@Infinite.mhs.compuserve.com | | FAX: +1-410-363-3779 | | Others: > NUL | | | +------------------------------------------------------------------+ Special thanks to all of those who participate and contribute in NOVB Section 15 on the NetWire forums on CompuServe, including: Jimmy Wright, Novell Rich Adams, volunteer NetWire Sysop Dennis Beach, volunteer NetWire Sysop Sandra Duncan, Novell Jon Hunt, Novell Mickey, Dave, Andy & Deb on NetWire Charles Rose, Author "NetWare Power Tools for Windows", coming soon from Bantam Books (1-800-223-6834 x9479 to order) Stephen Saxon, Author "Running Windows on NetWare" on M&T Books (1-800-533-4372 to order) Howard Marks, Co-Author "Networking Windows: NetWare Edition" on Sams Books Rick Smith, Synergy Computing Tom Berdan Greg McGovern David Chamberlain Alan Woolfson Barry St. John Peter O'Rourke Peter Hauptmanns Michael Hader Jim Reese ...and the original cast & crew of Gilligan's Island, for their inspiration